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Abstract 


FINDER is a new packet radio database application 
utilizing multiple connect and a specific syntax to allow 
emergency response personnel to ascertain the status of 
their family members during a disaster. This paper 
describes the history, scope, operation, and design 
philosophy of the FINDER system. 


1. Introduction 


FINDER (the Family INformation Database for 
Emergency Responders) is a multiple-connect, packet 
radio database designed to allow emergency responders 
such as firefighters, policemen, or amateur radio 
operators to ascertain the status and whereabouts of 
their family members during a widespread disaster that 
overloads normal communications channels, thus 
allowing the emergency responders to more effectively 
perform their duties. Family members check-in with 
voice operators located at fire stations, who relay 
information to one of up to eight packet operators, all 
of whom are simultaneously connected to a central 
database station running the FINDER program. 
Emergency responders concerned about family members 
need only provide their home telephone number to a 
voice or packet operator to obtain a listing of the 
current information about all members of their family. 
FINDER can also be used in a “person tracking” mode 
to manage general information about victims of localized 
accidents such as train wrecks, plane crashes, or other 
multiple casualty incidents. 


2. Purpose, Origins, and Scope 


Part Five of the Amateur’s Code reads: “The 
Amateur is Balanced...Radio is his hobby. He never 
allows it to interfere with any of the duties he owes to 
his home, his job, his school, or his community.” 
Following a disaster, a ham’s first concern is with 
his/her family, but the community also desperately 
needs his/her skills. FINDER is a way for the amateur 
radio operator to assist the community in such 
situations. 


FINDER is an acronym for the Family INformation 


Database for Emergency Responders. It is a 
multiple-connect, packet radio database environment 
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which enables emergency responders to determine the 
status of their families in the event of a widespread 
disaster. It is designed to address one problem that has 
long plagued emergency response organizations: in a 
widespread emergency that overloads the telephone 
system, how can the organization keep the emergency 
responders focused on the job when they may be 
distracted by concern for the welfare of their own 
family? FINDER offers a partial solution to this 
problem by using the capabilities of amateur radio and 
digital communications. FINDER allows emergency 
responders to ascertain their family’s welfare without 
leaving their duties, enabling them to more effectively 
concentrate on the disaster at hand. This can all occur 
in the absence of commercial utilities and without tying 
up critical tactical communication channels. 


2a. History of FINDER 


Although city and county officials have always 
been concerned about the possibility of delay in the 
response time of trained personnel to a disaster, it was 
not until the Fall of 1984 that serious consideration was 
given by Santa Clara Valley ARES to this problem. 
Specifically, Bud Enochs, KE6DN, presented a written 
proposal for an Amateur Radio Emergency Health and 
Welfare Distributed Data Network in October of 1984. 
Despite this comprehensive document, the idea stayed 
relatively dormant until November of 1985 when Dick 
Rawson, N6CMJ, submitted a similar proposal for a 
program called the Emergency Worker Locator System. 
After a great deal of study, N6CMJ concluded that such 
a plan would not be feasible for Santa Clara County 
insofar as he calculated that each operator would have 
to be capable of handling one message every 25 seconds 
(this was based on staffing 80 firestations with 10,000 
emergency workers with 2.7 family members each for a 
total of 37,000 messages being entered and 10,000 
messages delivered). 


Despite these pessimistic worst-case projections, 
subsequent experience in tracking riders in the annual 
Primavera Bicycle Tour proved that a multiple-connect 
packet radio database could successfully manage large 
amounts of real-time data. The Primavera database 


program was written by Frank Kibbish, WB6MRQ, and 
handled the progress of approximately 2100 cyclists 
passing through five packet-equipped checkpoints [I]. 


The DEC at the  time--Bill Robinson, 
WB60ML--had been keeping the county and city 
Emergency Managers apprised of the progress of the 
concept. Needless to say, the civil authorities were quite 
enthusiastic since it was clear that utilization of the 
hams could allow civil personnel to determine the status 
of their families during a disaster. 


The project--now known as_ the Locator 
Project--picked up again in October of 1986 when 
WBO6OML held a meeting for hams interested in devising 
a way to make the previous ideas work. At that time, 
Sharon Moerner, NOMWD, became the project manager 
and Dave Palmer, N6KL, and Weo Moerner, WN6I, 
took primary responsibility in writing the software that 
would make the idea a reality. Other hams became 
active on the committee (e.g., Don DeGroot, KA6TGE; 
Randy Miltier, N6HMO; Dick Rawson, N6CMJ; Glenn 
Thomas, WB6W; Don Tsusaki, WW6Z) and the project 
was ultimately renamed FINDER. The first 
demonstration of the software occurred in December, 
1986, and the first alpha test was held in January, 1987. 


The first countywide test of FINDER occurred May 
30, 1987. In a three hour time period, 24 of the county’s 
63 firestations were staffed by amateur radio operators; 
154 people--hams and their families--checked into the 
system. Another county wide drill is scheduled as part 
of the Simulated Emergency Test on October 17, 1987 
and it is planned to staff not only all the firestations but 
to also include the participation of city firefighters and 
their families. 


2b. Current scope of FINDER 


There has been considerable discussion concerning 
the type of traffic passed by FINDER since it could be 
viewed as either Health and Welfare traffic or as 
Priority traffic. The agencies hams serve determine the 
priority of the communications provided, and the 
information supplied by FINDER is considered to be of 
high priority by the Santa Clara County Fire Chiefs 
Association. 


Obviously, there are clear possibilities for 
extending the coverage of FINDER, both geographically 
as well as demographically. At some time, FINDER may 
serve other civil and public agencies. Due to limitations 
of bandwidth and operator staffing, however, it is not 
feasible to allow general public access to FINDER. 
Even at this stage in the project, however, city and 
county officials are quite supportive and are working 
with the hams in training emergency responders and 
their families in utilization of the system. 


In addition to FINDER’s primary role following a 
large scale disaster, it may also prove useful during 
localized emergencies (e.g., plane crash, train wreck, 
toxic spill) which require tracking of victims and 
supplies. (For an example of the value of packet radio 
in disasters of this sort, see [2]) A special mode of 
operation of FINDER, called “health and welfare” 
mode, has been established especially for these 
situations. Activation of FINDER in a multiple casualty 
incident enables crucial information to be efficiently 
passed outside of the disaster zone to an area which has 
normal telephone service. 


3. Overview of FINDER 


The central element of the FINDER svstem is the 
FINDER software and database. Up to eight packet 
stations may be connected to the database 
simultaneously, and these packet stations serve as the 
input/output ports for entering information and status 
requests. Each packet operator also serves as the net 
control station for a group of voice operators located at 
fire stations. The voice operators interact directly with 
the emergency responders and their family members to 
receive current information and to deliver responses to 
their requests. 


The FINDER software and database collects and 
organizes status information about emergency 
responders and their families. FINDER may be regarded 
as a specialized, multiple-connect BBS with a command 
set tailored to the handling of current information and 
status requests. Central to the concept is the fact that 
the various “concentrator” packet stations can connect 
to the database using any kind of AX.25 TNC and 
terminal that is convenient. In other words, all the 
specialized software (and hardware) that gives the 
FINDER system its personality is located at the main 
database station. This is in contrast to packet networks 
which require each user to have specialized hardware 
and/or or software in order to participate in the 
network. Such systems--while powerful--are not likely 
to be available in a large disaster such as an earthquake, 
because the number of operators with the required 
equipment may become vanishingly small. 


FINDER works in a relatively simple way: 
1. A family member goes to a nearby firehouse 


2. He/she fills out the FINDER data card containing 
the home phone number, the first name, status 
(ranging from “All is OK” to “Contact as soon as 
possible”), and intended location 


3. He/she turns the card in to the amateur radio 
operator on duty 


4. The ham reads the information (via voice) to his/her 
designated packet operator 


5. The packet op transmits the information to the 
database. 
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The information is retrieved when an emergency 
responder gives a voice operator his/her home phone 
number. The voice operator reads the status request to 
the packet operator. The packet operator keys in a 
simple search request to the database, and after a short 
delay, the database replies with the status of all persons 
sharing that home telephone number. 


The following is a quick sketch of how amateur 
radio operators work with FINDER: 


main database 


data Sk dees data 


concentrator concentrator 
voice voice voice voice 
Ops Ops Ops ops 


MAIN DATABASE: that packet station which 
serves to gather and store all the data which it 
receives from the data concentrators. 


DATA CONCENTRATORS: _ packet operators 
simultaneously connected to the main database. 
Each concentrator will be typing in data received 
from his/her voice operators. Currently, there can 
be no more than eight data concentrators connected 
to the database at any one time. 


VOICE OPS: voice operators located at fire stations 
throughout the county who utilize pre-designated 
simplex frequencies to communicate the information 
written on data cards to the data concentrator. The 
number of voice ops could range from two per data 
concentrator to as many as nine per data 
concentrator depending on the number of fire 
stations to be covered. 


4. FINDER - The Program 


The FINDER program is written in Turbo Pascal, with 
assembler code where needed for control of the serial 
port to the TNC. It is designed to run on an IBM 
Personal Computer@ or compatible, preferably with a 
hard disk, and requires a TNC (1 or 2) containing the 
firmware written by Ronald Raikes, WA8DED, which 
provides a “host mode” capability. 


4a. Multiple-Connect 


The multiple-connect feature is crucial to the 
efficient operation of FINDER. Multi-connect operation 
allows the available channel bandwidth to be used more 
efficiently, because at any given time many of the packet 
stations are involved with relatively slow keyboard 
input. This is in marked contrast to packet bulletin 
board systems (BBS’s) in which only one station may be 
connected to the system at a time. 
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4b. WASDED Host Mode 


WAS8DED host mode is utilized in the FINDER 
program to greatly simplify the parsing of the data 
streams from the various connected channels. Basically, 
the TNC does not speak to the PC until it is told to do 
so by a polling command, and then the TNC does not 
send bursts longer than 256 characters in length. This 
removes the difficulties associated with asynchronous 
data streams and leaves the problem of queuing 
transmitted and received packets to the TNC itself. As 
a consequence, the FINDER program can concentrate 
on polling the connected channels, handling the sysop 
keyboard and display, and managing the database. 


4c. The FINDER Database 


FINDER uses the Turbo Database Toolbox ® [4] for 
all database entry, indexing, and maintenance functions. 
This useful package of Pascal functions and procedures 
implements a full B+ tree structure that generates a 
database file and associated index files on disk to aid in 
database searches [5]. FINDER implements two index 
files for the standard emergency responder mode of 
operation: a telephone number index and an origin 
index. This means that the database can be searched 
very quickly for all entries with a given phone number 
or with a given origination point. The database file can 
contain as many as 65,535 records, each 35 bytes in 
length. 


4d. Svnopsis of FINDER command syntax 


1. Single letter commands: The single character "h" 
followed by a carriage return implements the help 
function, and a brief reminder of the syntax is 
returned to the packet op. The single letter "b" (for 
bye) followed by a carriage return initiates a 
disconnect from'the database machine. 


2. General rules for data entry: The various fields are 
entered in order, with separators between them. 
Valid separators are the comma and the blank. 
Multiple consecutive separators are treated as a 
single separator. Case is ignored. 


3. Syntax for CURRENT INFORMATION: (<cr> 
means carriage return) 


phonenum,aname,sl,orig,time,date<cr> 


See the FINDER DATA CARD (in the appendix) 
for an explanation of these fields. The first four 
fields are required, and the last two are optional. 


a. PHONENUM can have multiple embedded 
dashes; all dashes are ignored. Two general 
formats may be used: long form or short form. 
The long form uses the full ten digits for area 
code and phone number. The short form has 
only 8 digits, and uses a single leading digit as 
an abbreviation for the full area code. The 
allowed abbreviations are defined by the sysop 
in the configuration file. For example, “408” 
can be abbreviated "8", and “415” can be 


abbreviated “5”. The sysop may select no area 
code checking when the FINDER program is 
started. In this case, any ten digit phone number 
is accepted, but no 8-digit phone numbers. 


b. ANAME is a 5 character field with a leading 
letter, signifying the first 5 letters of the person’s 
first name. This identifies the specific family 
member. 


c. SL is a 2-digit code, which is a combination of 
the “My current status is” and “I will be at” 
codes on the data card. The two digits should 
be entered one after the other, with no 
characters in between. Only the values shown 
on the data card are allowed. 


d. ORIG is the 4-character code signifying the 
point of origin of the current information, i.e., 
the “This form filled out at” field on the data 
card. For instance, the code could be the fire 
station number where the person filled out the 
form. ORIG must start with a letter. 


e. TIME is an optional field. If present, it must be 
a valid 24 hour time (with no colon). If this 
field is not present, the database program inserts 
the current time. TIME must be entered, 
however, if an entry for DATE follows. 


f. DATE is an optional field. If present, it must 
be a valid day of the month. If this field is not 
present, the database program inserts the current 
day of the month. 


g. Examples of data input: 


85553195, joe,12,sj34<cr> 
415-555-2368,mary,11,pa34,1235,3<cr> 


These six pieces of information are stored in the 
database as a record of the status and location 
of the person at a particular time and date. 
Further CURRENT INFORMATION packets 
with the same PHONENUM and ANAME will 
supercede old information for that person. 


4. Syntax for STATUS REQUEST: 


/phonenum,voiceopid<cr> 
or 
?phonenum, voiceopid<cr> 


This command line instructs the database machine 
to look in the database for ALL persons with the 
same phonenum. A status report, listing all six of 
the pieces of information in 3. above is sent back to 
the packet station. At the end of the report, the line 
“FINDER report for <voiceopid> done at <time>” 
is sent, which signifies that no more names match 
the requested phone number. 


a. PHONENUM has the same restrictions as in 3.a. 
above. 


b. VOICEOPID is a free-form field of any length 


up to 255 characters with no embedded blanks 
or commas. It serves as a reminder to the packet 


operator of which one of his/her voice ops 
transmitted the status request. It is not stored 
in the database. It may be the same as the origin 
codes in 3.d. above, or it may be the voiceop’s 
callsign, or it may be any other convenient string 
of characters. 


c. Examples of status request: 


/8555-3195,wlaw<cr> 
/408-5553456,w6xyz<cr> 
/55558011,sj14<cr> 


5. Search by origin code: In addition to the phone 
number search, FINDER also supports a search by 
origin code in the form 


Sorig,routereplyto 


This produces a listing of all persons in the database 
whose current information originated at ORIG. 


6. Users command: The users command in the form 


"users<cr>" returns a list of the callsigns of 
currently logged-on packet stations. The response is 
of the form: 


At WN6I-1: N6KL, W6BB-3, AJ6T, WBOMRQ-7. 


7. Tell command: The Tell command 3110ws connected 


packet stations to use FINDER as a conference 
bridge. For example: 


Tell <callsigni! >[,<callsign2>][...] <message> 


The <message> is sent to the callsign(s) specified. 
The special callsign "'*" or “all” is used to send a 
message to all connected stations. The recipient 
stations receive the <message> prefaced with the 
time of day and the sending station’s callsign, e.g.: 


1630 N6KL> Has Resource Net moved to 146.94? 


8. Message to sysop: Any other packet that does not 
start with a number, "/", '?", “tell.” or “users” is 
treated as a message to the sysop. An 
acknowledgment message of the form 

Msg sent to sysop at <time>” 
will be sent back to the packet operator. The sysop 
can also send messages to the packet operator. 


4e. Special sysop commands 


The sysop keyboard accepts current informat ion 
input and search requests like any connected channel. 
The sysop can also send commands directly to the TNC 
by typing <ESC> and the command as usual. Some 
commands (such as "|" for list) can reference a specific 
channel. To set the channel for these commands, first 
type "<ESC>sn", where n is the channel number. For 
example, to force a disconnect on channel 3, the sysop 
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types "<ESC>s3 <cr> <ESC>d <cr>" The sysop can 
also send messages to connected channels by typing 
"<ESC>nmessage" where n is the channel number. If 
the printer is enabled by pressing a PF key, the printer 
echoes all sysop screen output. 


Several useful database functions may also be 
performed by the sysop. A summary of the number of 
database entries for each ORIG or each CLOC can be 
produced by typing "s<cr>". A single record in the 
database can be listed if its record number is known by 
typing “1 nnn <cr >", where nnn is the record number. 
All database entries can be listed by typing “1 all<cr>". 
Finally, a single record may be deleted by typing "d 
nnn<cr>", where nnn is the record number. For 
obvious reasons, all these commands are restricted to the 
sysop only. 


5. An Important Extension - FINDER Health and Welfare 
Mode 


In certain emergency situations, a record format 
more flexible than what has already been described is 
useful. In a multiple casualty incident, one might like to 
record a telephone number, full first and last names, a 
current location, plus perhaps a long message that might 
describe other important information. For these 
situations, a second operating mode of the FINDER 
system has been implemented, called the “health and 
welfare” mode, although the “person tracking” mode 
might be more descriptive. If FINDER were used for 
patient tracking, for example, the traffic would be 
regarded as priority traffic, so the utility of this mode 
extends beyond simple health and welfare. 


To prevent confusion, the mode of FINDER 
described before this section will be called the 
“emergency responder’ (ER) mode, while the extended 
mode will be called the “Health and Welfare” (HW) 
mode. The operation of the HW mode is fully analogous 
to the ER mode operation, except that the data record 
format is changed and several additional searches are 
allowed. The HW mode is selected by running a 
different batch file, “FINDHW”, at startup, and the 
database, index, configuration, and journal files are 
distinct and separate from those for the ER mode. 


5a. HW Mode Data Input Format 


The HW mode data input format is well-suited to 
health and welfare traffic and patient/victim tracking. 
Because fewer records would be expected under these 
conditions, the various fields are generally longer and 
more flexible. The HW data input format looks like: 


phonenum, lastname, firstname,cloc,message 


where 


1. PHONENUM is an abbreviated 8-digit or a full 
lo-digit phone number with syntax identical to that 
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for the ER mode. It could be the victim’s home 
phone number or the phone number of next-of-kin. 


2. LASTNAME is the last name of the person, up to 
10 characters long. 


3. FIRSTNAME is the first name of the person, up to 
10 characters long. 


4. CLOC is a 4-character location code starting with a 
letter. It could be a hospital code or a shelter code 
defined in advance or in real time during the 
incident. This field is similar to the origin code field 
in the ER case, except that instead of stating the 
location where the FINDER data card was filled out, 
CLOC is more general. 

5. MESSAGE is a free-form field up to 45 characters 
in length which may contain embedded blanks. It is 
intended for additional information about the 
person, such as name of nearest relative, injuries, 
etc. that is determined to be useful during the 
incident. 


6. The current time and date are inserted automatically 
by the program. 


5b. Searches Available in HW Mode 


1. /phonenum,routereplyto 


e produces a list of all entries with the same 
phonenum 


2. /lastname,routereplyto 
e searches by lastname, listing all with the same 
lastname 
3. $cloc,routereplyto 
e searches by cloc. As an example, this could give 
a listing of all persons sent to the same shelter 
or hospital 


6. Configuration file processing 


A number of run-time parameters must be selected 
by the sysop to start FINDER. These are collected in 
an ASCII file called FINDER.CFG (or FINDHW.CFG), 
which needs to be edited only once to specify such- 
parameters as the journaling/backup drive, journal file 
name, prompted or automatic program startup, the 
backup interval, the RS232 comm port, TNC baud rate, 
area code checking, and area code abbreviations. 


7. Backups, Journals, and Data Recovery 


Once a transaction has been saved on disk or 
diskette, a number of safeguards against data loss are 
taken automatically. For each backup or journal entry, 
the relevant files are opened, updated, and then 
immediately closed. First, a journal file is used to record 
each valid transaction at the time it is entered. Second, 
FINDER automatically makes periodic backup copies of 
the entire -database and the index files. This backup is 
made after every '"n" transactions, where the value of 
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n’ is specified by the sysop in the configuration file. 


This backup also occurs following any disruption in the 
computer--TNC link, or at any time the sysop presses 
"Fi" on the keyboard. 


Recovery steps may be required in the event that 
the power is removed during a disk write operation. In 
this case, the main database file (or it’s entry in the DOS 
directory) may become damaged, and some combination 
of the journal or backup database files may be needed 
to reconstruct the data. A utility program called 
“Rebuild” is supplied and provides a number of recovery 
options. Rebuild can append the contents of the journal 
to the previously saved version of the database, can 
rebuild the index files from a working database file, can 
construct a set of database and index files from a journal 
file, and can generate a printed copy of the database. 


8. Computers and Packet Radio in Disaster Environments 


Computers and packet radio networks can be 
somewhat fragile. They can be confusing to operate, 
they contain multiple sources of error (due to hardware, 
software, and users), and they do break. Because 
FINDER is designed to work under the worst possible 
circumstances, a number of precautions are built-in to 
insure that data will not be permanently lost, and that 
when failures do occur, the data can be reconstructed 
easily. 


For each transaction entered by a connected packet 
station, the FINDER program responds with some kind 
of time-stamped acknowledgement [ 6]. Once a packet 
operator receives this acknowledgement, he/she knows 
that the transaction has been safely written to disk or 
diskette. The syntax of the commands described above 
is thoroughly checked so that many typing mistakes can 
be caught automatically. In case of entry errors, a brief 
message is sent that identifies the problem. The packet 
operator can check on the health of the FINDER 
program by sending a single carriage return <cr>. If 
FINDER is running correctly and actively polling for 
incoming data, it will respond with a single <cr>. 


If the database is up and running, it is best for 
operators to transmit data as it arrives and avoid 
buffering large numbers of transactions in their 
terminals. This is because operators may miss any error 
messages that would be sent during the upload process 
if any of the transactions contain errors. In addition, if 
the packet link becomes severed in the middle of an 
upload, AX.25 does not make clear how many 
transactions may have been lost. (However, there is no 
penalty for re-entering duplicate data other than the 
time wasted). 


Picking the correct set of TNC link parameters is 
an important art. For the same reasons that buffering is 
usually not helpful, it is best for user TNCs to send only 
one outstanding, un-acknowledged packet at a time (e.g. 
set MAXFRAME to 1). This keeps a packet station 
with a marginal path from saturating the channel with 


subsequent packets and retries that are likely to be 
discarded. Also, the nature of the user interaction in this 
application is such that MAXFRAMEsS1 is a natural 
setting [7]. 


The TNC’s FRACK parameter controls the amount 
of time the TNC waits for a frame acknowledge. 
FRACK should be set high enough to_guard against the 
“hidden transmitter’ problem. In one drill] a user’s TNC 
continued to retry packets about once every second 
because it could not hear other stations. Since the 
database TNC heard most users directly, it sensed the 
channel was busy and was held off while his and other 
user’s packets collided repeatedly. A FRACK value of 
10 seconds or higher is probably about right. In any 
event, local implementers should determine a set of 
parameters that work best for their environment, and 
then encourage all packet stations to use the same set. 


While the FINDER database can be configured to 
start automatically and run without intervention, the 
sysop plays an important role in keeping the system 
working well in the presence of marginal paths. The 
sysop display screen is updated continuously with the 
results of the TNC’s link status for each channel. The 
display provides the number of: 


e Receive frames not yet processed 

e Frames sent to the TNC but not yet transmitted 
e Frames transmitted but not yet acknowledged 

e Retries on the current operation 

e Link status messages not yet displayed 

The AX.25 link state. 


By keeping close watch of the number of retries and 
the AX.25 link state, the sysop can spot which packet 
stations on the network may be suffering from marginal 
paths. In these cases, the sysop can recommend (either 
via voice or by packet message) that the packet operator 
make changes in his/her antennas, TNC parameters, or 
radios. The sysop can also force the logoff of any user 
and then allow reconnect via an alternate digipeater 
path. In the event that the (database computer has been 
down for a while and packet stations have been forced 
to buffer their data locally, the sysop may ask that 
stations take turns uploading data, especially in areas 
where the terrain would make the “hidden transmitter” 
phenomenon a problem. 


When FINDER is activated, selecting which 
available packet stations will serve as packet 
concentrators is an important decision. The packet 
stations must have a good path to the database, and 
must also have good signa‘s to their voice operators. 
As has been observed numerous times, if both the 
database packet frequency and the voice simplex 
frequencies are in the same amateur band, steps must be 
taken to minimize desense between the packet operator’s 
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voice and data radios, For this reason, moving the 
database to, say, 220 MHz, is ideal if enough 220 
MHz-equipped stations are available when the disaster 
strikes. 


9. Getting Your Copy of FINDER 


The FINDER program is in the public domain; 
permission is granted for non-profit, non-commercial use 
only. The FINDER program is available from WN6I] or 
N6KL by sending a blank, formatted 5 1/4" or 3 1/2" 
diskette with SASE for return to you. If you wish to run 
FINDER without changing the code, the cost to you is 
the cost of the diskette and return postage. Note that a 
configuration file facility is included so that you can 
tailor certain parameters to your system without 
changing the code itself. If you want small changes in 
the code, attempts will be made to try to accommodate 
you. In any event, your comments and suggestions are 
welcome. 


10. Conclusions 


The FINDER system is ready to be utilized to 
enhance the response of emergency service personnel 
during a widespread disaster. The FINDER system is 
what it is today as a result of the many hours of work 
donated by the FINDER committee and by the hams 
who have participated in the operational tests. In 
addition, the support of the Santa Clara Valley ARES 
has been invaluable as has been the response shown by 
city and county officials familiar with FINDER. 
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APPENDIX 
FINDER Data Card 


ARES FINDER ~ Family Information Database for Emergency Responders 
(Complete one or both sides, as appropriate) 


Fill out this side if entering 


Fill out this side if requesting [ 
information about yourself. 


information about your family. 


STATUS REQUEST CURRENT INFORMATION 


|_| 408 |_| 408 
= Home Phone:!_{}_{_}-}_}_}_}_} Home Phone:}_!}_!_{-/_{_!_!_} 
jt 415 :_} 415 

First Name........ ehalelesee dl Pca Ded 


MY CURRENT STATUS (circle only one): 


All is OK . ia PSG Fas ee saa 39 44S 1 
OK--contact when convenient ..... 2 
Contact me as soon as possible . . 3 


I WILL BE (circle only one): 


At HOME> Aiervesa seg erétereienise ares ieee wae 
At work ....5. SSievecb's: waar Wie ele wae 2 
At relative . . cesses nsanerreraee io 3 
At neighbor « .ssesseieaeecoseuese 4 
At hospital . . e+ -eneeennneennnoe 

Ate ‘SCHOOL: vii y ieiecessaie wiscace@ areateletecere? 6 
Ate -SHELECE (i cr deere Sie ea aie Sate o ecece. 
At previously agreed upon place.. 8 
On assignment 9 

Other ..ee.... seas 


This form filled out at: }_{_}!_}_} 
(Origination Point) 


Time (optional): |_{_{!_!_t (24 hour) 


Today's Date (optional): |_{_} 


(Day only) 


(reverse side) 


FINDER Data Card 
ARES FINDER = Family Information Database for Emergency Responders 


STATUS REPORT 


Time Telephone Status |Originate 
Received Point 


\ { 
Provided as a Public Serwice by Amateur Radio 
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